Figure 1: Example of display ID hardware for supporting double
buffering. The pixel shown is assigned display ID 5 meaning
the pixel should be treated as a double buffered, color index
pixel with buffer A being the displayed buffer.
Display mode IDs (often called DIDs) are like CIDs, but instead of providing clipping information, DIDs determine on a per-pixel basis how each pixel value on the screen should be displayed. The DID for a pixel is looked up in the hardware display mode table to determine how the pixel should be displayed. The DID mode indicates whether the pixel is RGB or color index (i.e., the color is determined by a colormap); if color index, what hardware colormap to use if there is more than one; the depth of the pixel (how many bits of the pixel value are significant); if the pixel is double buffered, and if so, what buffer (A or B) should be displayed. Figure 1 gives an example of how a DID determines how a pixel should be displayed.
Logically, DIDs are stored in a set of non-visible frame buffer planes. Usually 16 or 32 DIDs are available. In low-end hardware, devoting 4 to 5 bitplanes per pixel to store the DID is too expensive. In this case, the DID values are run-length encoded. This encoding is convenient becauses the frame buffer is scanned out in horizontal lines. But logically, there is still a DID per pixel. In principle, a complex arrangement of display modes on the screen might be too complex to represent with a run-length encoded table. In practice, run-length encoded DID tables work extremely well.
Note that many windows can all share the same DID if their pixels all use the same display mode. For example, all non-double buffered 8-bit color index windows using the same colormap can share the same DID.
When a process requests a buffer swap for a window (in OpenGL, glXSwapBuffers would be called), a double buffer window must have an unshared or swappable DID. This is because the buffer swap is accomplished by toggling the displayed buffer for the window. If the pixels for the window (and only the pixels for the window) are all in the same DID, the buffer swap happens cleanly. What this means is a double buffered window that needs to swap must be placed on an unshared DID before the swap can happen. Like CIDs, the number of DIDs is limited by hardware so DIDs may also need to be virtualized.
While DIDs and CIDs are discussed here as distinct entities, it is possible to combine display mode and clipping information into a single set of bitplanes. This may be useful because often the clipping ID planes and display mode ID planes both have the same regions each assigned a CID and DID. Combining CIDs and DIDs can make better use of frame buffer memory. If 32 DIDs were supported and 4 CIDs were supported, a combined scheme would support 128 combined DID/CID values! But combining DIDs and CIDs means DID information cannot be run-length encoded. This is a graphics hardware design trade off.